home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16238 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB
  1. Path: news.nyu.edu!schonberg!dewar
  2. From: dewar@cs.nyu.edu (Robert Dewar)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 9 Apr 1996 20:46:55 -0400
  6. Organization: Courant Institute of Mathematical Sciences
  7. Message-ID: <dewar.829096975@schonberg>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com> <dewar.829011320@schonberg> <4kcsnsINNgkb@keats.ugrad.cs.ubc.ca> <dewar.829051685@schonberg> <829066525snz@genesis.demon.co.uk>
  9. NNTP-Posting-Host: schonberg.cs.nyu.edu
  10. X-Newsreader: NN version 6.5.0 (NOV)
  11.  
  12. Lawrence says
  13.  
  14. "Correctness considerations aside, there is never a good reason to pass
  15. a value in the 3rd argument to read() that is greater than the available
  16. buffer size. IMHO code that does this is highly suspect whether or not
  17. you argue that it is legal. I wish more systems were like Linux and trapped
  18. this, maybe they will in the future."
  19.  
  20. Highly imprecise thinking here I fear. There is no practical way for
  21. any implementation to do the check you mention (this = value in 3rd
  22. argument that is greater than the available buffer size). This is
  23. C remember! We are passing a pointer, the caller routine has no way
  24. of knowing the buffer length, and in general unless you keep structured
  25. pointers which now the bounds of the object they reference (something
  26. no real C compiler does), there is no way to make the check.
  27.  
  28. Linux simply checks that the end of the buffer is in the memory area,
  29. which is not the check you would like to see. That's what I was talking
  30. about when I noted that this kind of uncertainty would not occur in
  31. a language with a reasonably complete type model.
  32.  
  33. What exactly *is* the wording of the POSIX standard here (Lawrence, you
  34. must have it at hand, please quote it exactly). The interesting thing
  35. is to determine whether this definition says enough to make *any* use
  36. of read defined without appealing to "unwritten rules". I would guess
  37. not!
  38.  
  39.